docs(plugin-dashboard): README's chart example taught a rejected type: 'card' widget - #7951

Fixes #7035

The README's "Dashboard with Charts" example put two widgets spelled type: 'card' with a
nested body into widgets[]. Measured, not read off the type: @object-ui/types/zod's
DashboardComponentSchema.safeParse returns invalid_union at widgets[1] and widgets[2],
so a reader who copied the block got a rejection. 'card' is not a member of
DashboardWidgetTypeName, the vocabulary #4600 closed.

Both are now the chart-family widgets the renderer actually dispatches — line and pie,
with inline rows under options.data and options.xField / options.yField — plus one
paragraph stating the rule the example now follows.

The card's population is smaller than the measurement predicted — and the other half is a fork, not a fix

Comment 5523309430 widened this card from one fence to four blocks that put a
component-shaped node straight into widgets[], leaving open which side was wrong.
Measured on a2e10cf96, the answer splits, and only one half is a docs defect:

metric-card in a widget slot is not an accident of tolerance: DASHBOARD_COMPONENT_WIDGET_TYPES
(packages/types/src/complex.ts:1568) admits it by the 2026-08-14 maintainer ruling
(objectstack#8593), the Zod widget slot is a union whose first arm is exactly that component node
(packages/types/src/zod/complex.zod.ts:887 over :749), and classifyWidgetType returns
passthrough for it on purpose. So those three blocks are left byte-untouched.

What the same measurement did surface is a divergence this PR deliberately does not touch,
because it lives in packages/types and is a published-contract decision:
DashboardComponentSchema.widgets is declared DashboardWidgetSchema[]
(complex.ts:1733) with no component-node arm, so annotating the legal metric-card examples
yields TS2561: 'value' does not exist in type 'DashboardWidgetSchema' — the Zod mirror accepts
a whole arm the TypeScript declaration refuses. That is filed as #7952 and is not addressed
here — it is a packages/types decision, and #7952 also records why the parity ledger files
that key as SCHEMA-NODE and so sorts it out of #7759's disposition lane.

What was measured

Everything below ran on 70ea5b79b.

Before. The batch-10 diagnostics reproduced against the built dist/, --strict:

error TS2561: Object literal may only specify known properties, but 'value' does not exist
              in type 'DashboardWidgetSchema'. Did you mean to write 'values'?      (x5)
error TS2322: Type '"card"' is not assignable to type 'DashboardWidgetTypeName | undefined'. (x2)

Renderer. Each shape rendered through the shipped DashboardRenderer with
@object-ui/plugin-charts registered: the type: 'card' widget paints Unknown component type: line-chart … (OBJUI-001); the rewrite paints two charts and no OBJUI-001; a mis-spelled
type stays red. (Scratch harness, not committed.)

After. Every dashboard block extracted from the file — not retyped — parses:

:48 Automatic Registration => ACCEPT      :217 Dashboard with Charts        => ACCEPT
:129 Dashboard            => ACCEPT      :257 Responsive Dashboard         => ACCEPT
:178 Basic Dashboard      => ACCEPT      :275 Integration with Data Sources => ACCEPT
6 dashboard block(s); 0 rejected.

Ablation. Reverting the block to the type: 'card' spelling turns the new test red on
exactly that block, naming both widgets — mutation proven on disk (type: 'card' count 0→2,
type: 'line', count 1→0, blob hash changed), restore proven byte-identical to the HEAD blob:

× :217 Dashboard with Charts validates against the shipped DashboardComponentSchema
AssertionError: README.md:217 ("Dashboard with Charts") is refused:
  invalid_union at widgets1: Invalid input; invalid_union at widgets2: Invalid input
Tests  1 failed | 6 passed (7)

Why a test file

No gate asked this question, each for a stated reason: check:doc-snippets compiles fenced
ts and these are untyped const schema = { … } literals (its header names schema-key
validity as the question it does not answer); check:doc-types walks content/docs/** and the
root README, so package READMEs are outside it (#7896, whose live-instance list this README's
unregistered line-chart joins); check:readme-exports judges import bindings. The new test is
this document only, and follows plugin-gantt/src/readme-navigation-example.test.ts — the same
pattern one package over.

Gates

The repo-wide pnpm lint and the rest of the farm are CI's.

Generated by Claude Code